![[レポート] ARC202: リーン・アーキテクチャ：コスト効率への最適化方法 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2018/11/eyecatch_reinvent-2018-city_1200x630.jpeg)
[レポート] ARC202: リーン・アーキテクチャ：コスト効率への最適化方法 #reinvent
開催中の AWS re:Invent 2018 会場より、11/26（現地時間）行われた下記セッションをレポートします。
セッションタイトル
- ARC202-R Running Lean Architectures: How to Optimize for Cost Efficiency
概要
セッション概要より抄訳：
このセッションは、サービス選択や構築を通して、コスト効率の高いアーキテクチャに到達するまでにフォーカスしている。このセッションでは、コンテナやサーバレスといった主立った技術トレンドをカバーしつつ、AWSで何が可能になるのか、最適化にとっては新しいワークロードを採用することと既存のワークロードを改良することのどちらが良いのか理解を深めてもらう。あとハムスター。
Aimed at solutions architects and technical managers, this session focuses on the practical ways our customers achieve cost-efficient architectures through service selection and configuration. We start by discussing the building block services. We cover the main trends, such as containers and serverless, and we explore some of the specific services and configurations customers have used. We also take you through real-life examples that can be implemented to minimize costs while driving innovation and business output. After you attend this session, you will understand what is possible on AWS, and you will know ways in which you can deploy new workloads or modify existing workloads for optimization. (snip)
TL;DR
- 使わないインスタンスをOFFに
- Auto Scaling やその他自動処理を使う
- EC2 Spot インスタンスを使う
- コンテナを検討する
- 同期的・排他的・待ちの発生するコードを撲滅
- いつでもどこでもキャッシュする
- マネージドサービスを使う
Speaker
- Constantin Gonzalez - Principal Solutions Architect, AWS
- Jean-Cedric Desrochers - Principal Software Dev Engineer, Expedia.com
- Patrick Blanchette - Senior Software Developper, Expedia.com
資料
動画
内容
このセッションで得られるもの
- AWS からの請求書を少なくするためのベストプラクティス
- さらにスケーラブルで、強靱で、ダイナミックな アーキテクチャ
- 革新のための時間
- 実装の簡便さ
AWS の値付けの文化
- さらなる顧客
- -> さらなる AWS の使い勝手 <- コミュニティ、拡大、新機能、新サービス
- -> さらなるインフラ
- -> 経済圏の拡大
- -> インフラコストの削減 <- インフラに対する革新
- -> 価格の低下 -> 1. に戻る
2006年から 67 回の値下げを実施
AWS は開発者のために
- 構築せよ
- 稼働させよ
- 最適化せよ
- 最大の強みは アーキテクチャの柔軟性
- 最終目標は 無駄なサイクルの除去
- 必要ではないリソース
- 待機中のリソース
- 繰り返しの（たいくつな）作業
コスト最適化のプロセス1 - 計測
- AWS billing dashboard の確認
- AWS Budget のセットアップ
- AWS Cost Explorer
コスト最適化のプロセス2 - アーキテクチャ
- 不要な（使っていない）インスタンスを落とそう
- 開発用、テスト用、トレーニング用のインスタンス
- インスタンスの stop / start を使おう
- EC2、RDS
- 構成ごと on / off させよう
- CFn, HashiCorp Terraform 他
- 不要な構成はまとめて削除、必要になったらプロビジョニングする
- 考えどころ：捨てて良いインスタンス
- ある顧客は、これで 35% 節約しました
- 全てを自動化しよう
- 自動的なインスタンスの on / off サイクル
- AWS SDK
- AWS CLI
- AWS CloudFormation
- AWS OpsWorks
- Netflix Janitor Monkey
- Auto Scaling
- Auto Scaling のゴール
- 自動的なキャパシティマネジメント
- 自動的な障害からの復旧
- 自動的なコスト最適化
- Auto Scaling は DynamoDB でも使える（ようになった）
ペットと家畜（Cattle）の比喩
- ペット - 旧来の IT マインドセット
- 個々の（それぞれが個性を持った）サーバ群
- 手動管理
- 設計と設定に差が生じる
- 潜在的なエラー
- 沢山のおしごとが発生
- 家畜 - 新しいマインドセット
- 高い標準製
- 高い自動化具合
- 潜在的なエラーが少ない
- やらなきゃならないことが少ない
- とても効率的
- コスト削減！
EC2 Spot インスタンス
- とは
- 予備のコンピューティング容量
- 大幅なディスカウント
- 2分前に停止予告
- 常時オンデマンドより安い
- スポットインスタンスアドバイザー
- EC2 スポットフリート
事例: Expediaグループでのコスト最適化
（登壇者交代）
旧アーキテクチャ（オンプレ）
- Pivotal GemFire を使用
- 1,500 〜 2,500 トランザクション毎秒(TPS)
- 1クラスタあたりで 400 TPS
- 99パーセンタイルで 600〜800ms
- スパイク時はレスポンスタイム 1.5s超
- サードパーティコスト
- レガシーアーキテクチャ
- 動かせるハードウェアが入手不可能
- サポート
クラウド試験使用 Lift + shift
- 旧来のアーキテクチャをそのままクラウドに
- めちゃ高い
- 大きな EC2 インスタンスタイプは高い
- 古いアーキテクチャはデータ圧縮に対応していない
- 一ヶ月後：良い勉強だった！
新アーキテクチャ
- ElastiCache クラスタを導入、オンデマンドのスケールアウト・スケールイン
- 二段目（L2）キャッシュとして RDS
- キャッシュノード異常の検知と自動復旧
- アプリ側でのフィルタリング
- 性能
- 4,000〜8,000 TPS（旧 1,500〜 2,500）
- 99パーセンタイルで 90〜180 ms（旧 600〜800 ms）
- 99.9パーセンタイルで 180〜360 ms
- シンプルなアーキテクチャ
- コスト削減
- サービスの安定向上
- サービス利用者が戻ってきた :)
- 環境の柔軟性向上
Lift + shift パート 2
- シンプルなクラウドアーキテクチャへ移行
- GemFire から memcached と MySQL に
- 成果
- ひとつのコードベースで何処でも動かせるように
- 複雑なプロプライエタリ製グリッドからの脱却
- オープンソース
- 一方で…
- クライアントがクラウドへの移行を完了するまでの一時的なもの
- 同じアーキテクチャでも、DCとAWSでレスポンスタイムが安定しない
Geo プロジェクト - クラウドへのマイグレーション
- 要件
- 低レイテンシ
- 重書き込み（コスト最適化）
- 大きなペイロードのサポート（1kB以下 -> 100MB）
- 初期設計から、最終的には EC2 + Cassandra を永続的キャッシュとして追加
- S3, Aurora, DynamoDB などを試用して落ち着く
- i3 インスタンスは NoSQL 向き
- 最終構成
- 86% のコスト削減に成功（ 110万ドル/年 ）
- 4倍のスケールキャパシティ
- クライアントには移行のインパクトなし
- むしろ 25% 高速、ペイロードの +1MB 増加
Geo の今後
- Spot インスタンス導入
- Spot インスタンスが使える構成 = 「点火して放置（fire + forgot）」
- 「障害時の緩和策」とか考えなくて良い
- カオスエンジニアリング Ready!
- Cassandra 用の EC2 を Spot に
- -> 25%〜45% の削減
- 全体では 20%の削減へ
事例紹介終了
（もとの登壇者と交代）
- 削減対象の残りの部分について説明
- 必要ではないリソース
- 待機中のリソース
- 繰り返しの（たいくつな）作業
Spot インスタンスのユースケース
- コンテナ化されたワークロード
- ビッグデータ、Amazon EMR
- CI/CD
- HPC
- 経済シミュレーション
- メディアのレンダリング/トランスコーディング
- Amazon EC2 スポットインスタンス | AWS
「とはいっても、各インスタンスで沢山のアプリケーション動かしてるんだよね」
- …という場合には、アプリを コンテナ 化する
- EC2インスタンスの利用効率も上げられる
- 手順
- まずはそのアプリをステートレスにする <-
- ECSかEKSかFargateを使う
- Spotインスタンスを利用する
- ね、簡単でしょう？
サーバーレスもあるよ
- AWS Lambda を使ってアイドルタイムを削る
- 自動的なスケーリング
- 自動的なプロビジョニング
- インフラの管理は不要、ただコードを持ってくるだけ
- 稼働率が 40% 以下なら Lambda を検討してください
- コード内に sleep （待ち時間）があるなら、代わりに Step Functions を
キャッシュ
- 一度用意したものは可能な限り使い回そう
- メモリはCPUより安くて早い
- ハムスター = 食料をため込む習性 = 一時的貯蔵 = キャッシュ
キャッシュは何処にでも
- Database -> ElastiCache
- App -> DynamoDB Accelerator(DAX)
- Web
- Edge -> CloudFront
- Client
繰り返し作業の削減
- 既存のマネージドサービスを使う
- 例：Amazon EMR から Athena へマイグレーション
ワークロードを分けて最適なDB選択を
- 何でもRDBMSを使うのではなく
- DynamoDB
- KVS、スループット、レイテンシ
- Athena
- 複雑なデータ、クエリ、スケーラビリティ、ストレージ
- Redshift
- Big Data、レイテンシは高い
- ElastiCache
- KVS、インメモリ、非常に低いレイテンシ
まとめ
- 使わないインスタンスをOFFに
- Auto Scaling やその他自動処理を使う
- EC2 Spot インスタンスを使う
- コンテナを検討する
- 同期的・排他的・待ちの発生するコードを撲滅
- いつでもどこでもキャッシュする
- マネージドサービスを使う
- 下記も活用のこと：
- AWS Trusted Advisor
- AWS Well-Architected program
所感
「コスト削減」というありきたりなテーマと思いきや、直接的なだけでなく設計・アーキテクチャまで踏み込んだ、非常に聞き応えのあるセッションでした。クラウドネイティブにすることで、性能も、革新性も、運用性もあがるだけでなく、コスト効率まで上がるということを再認識しました。
ちなみに検索すると、2014 年から同じタイトルで毎年セッションが行われている模様です。見比べてみると面白いかもしれませんね。
